Drop temporaries created in a condition, even if it's a let chain #102998

nathanwhit · 2022-10-13T01:31:18Z

During the lowering from AST to HIR we wrap expressions acting as conditions in a DropTemps expression so that any temporaries created in the condition are dropped after the condition is executed. Effectively this means we transform

if Some(1).is_some() { .. }

into (roughly)

if { let _t = Some(1).is_some(); _t } { .. }

so that if we create any temporaries, they're lifted into the new scope surrounding the condition, so for example something along the lines of

if { let temp = Some(1); let _t = temp.is_some(); _t }.

Before this PR, if the condition contained any let expressions we would not introduce that new scope, instead leaving the condition alone. This meant that in a let-chain like

if get_drop("first").is_some() && let None = get_drop("last") {
        println!("second");
} else { .. }

the temporary created for get_drop("first") would be lifted into the surrounding block, which caused it to be dropped after the execution of the entire if expression.

After this PR, we wrap everything but the let expression in terminating scopes. The upside to this solution is that it's minimally invasive, but the downside is that in the worst case, an expression with let exprs interspersed like

if get_drop("first").is_some() 
    && let Some(_a) = get_drop("fifth") 
    && get_drop("second").is_some() 
    && let Some(_b) = get_drop("fourth") { .. }

gets multiple new scopes, roughly

if { let _t = get_drop("first").is_some(); _t } 
    && let Some(_a) = get_drop("fifth") 
    && { let _t = get_drop("second").is_some(); _t }
    && let Some(_b) = get_drop("fourth") { .. }

so instead of all of the temporaries being dropped at the end of the entire condition, they will be dropped right after they're evaluated (before the subsequent let expr). So while I'd say the drop behavior around let-chains is less surprising after this PR, it still might not exactly match what people might expect.

For tests, I've just extended the drop order tests added in #100526. I'm not sure if that's the best way to go about it, though, so suggestions are welcome.

by the end of the condition's execution

rust-highfive · 2022-10-13T01:31:22Z

r? @davidtwco

(rust-highfive has picked a reviewer for you, use r? to override)

nathanwhit · 2022-10-13T01:51:44Z

Hmmm not sure what that ICE in CI is about, I can’t reproduce it locally. I’ll have to take a deeper look later.

src/test/ui/drop/drop_order.rs

compiler/rustc_ast_lowering/src/expr.rs

Noratrieb · 2022-10-13T06:17:48Z

Does this also fix #100276?

davidtwco · 2022-10-13T12:48:48Z

r? @compiler-errors

compiler-errors · 2022-10-13T17:56:20Z

I am not qualified to approve this PR i think 😂

r? compiler

also returning to author to fix the bug

@rustbot author

eholk · 2022-10-13T23:12:01Z

Hmmm not sure what that ICE in CI is about, I can’t reproduce it locally. I’ll have to take a deeper look later.

I ran into an issue recently that only showed up in CI. I was able to repro it locally by runner the tests in docker: https://rustc-dev-guide.rust-lang.org/tests/docker.html

Maybe that would help here?

nathanwhit · 2022-10-14T02:10:01Z

Does this also fix #100276?

Hmm unfortunately not, it seems to be a separate bug. (Though now that I'm looking at it, I think I actually might know the problem there - I'll try to open a separate PR, hopefully soon-ish).

nathanwhit · 2022-10-14T02:13:49Z

Hmmm not sure what that ICE in CI is about, I can’t reproduce it locally. I’ll have to take a deeper look later.

I ran into an issue recently that only showed up in CI. I was able to repro it locally by runner the tests in docker: https://rustc-dev-guide.rust-lang.org/tests/docker.html

Maybe that would help here?

Ah, I was actually able to fix it based on @compiler-errors comment, but thanks for the pointer! I'm sure it'll come in handy in the future.

With the latest commits I think this should be ready for review, so
@rustbot ready

joshtriplett · 2022-10-14T11:50:54Z

The behavior change seems correct to me. (No comment on the implementation.)

eholk · 2022-10-14T16:25:43Z

The implementation seems reasonable to me, so this PR seems good to go.

@bors r+

bors · 2022-10-14T16:25:44Z

📌 Commit 4e1c09d has been approved by eholk

It is now in the queue for this repository.

cjgillot · 2022-10-14T18:14:49Z

src/test/ui/drop/drop_order.rs

+        if let Some(_d) = self.option_loud_drop(18) // 5
+            && let Some(_e) = self.option_loud_drop(17) // 4
+            && self.option_loud_drop(14).is_some() // 1
+            && self.option_loud_drop(15).is_some() { // 2


The drop order is a bit surprising. IIUC, we start by dropping the first regular conditions in reverse source order, then other regular conditions in forward source order, then the block, then the let conditions.

Why the forward/reverse mix?

Yeah that's definitely a quirk. It's pretty much because for that condition we go from an AST like

// Fake notation - the numbers correspond to the argument to `option_loud_drop` Binary(And, Binary(And, Binary(And, Let(18), Let(17)), MethodCall(14)), MethodCall(15)

to hir like

Binary(And, Binary(And, Binary(And, Let(18), Let(17)), DropTemps(MethodCall(14))), DropTemps(MethodCall(15)))

Ideally we could group

self.option_loud_drop(14).is_some() // 1 && self.option_loud_drop(15).is_some() // 2

into the same DropTemps and then they would drop in reverse source order, but due to the nesting, I can't see a way to wrap them in the same DropTemps without the let conditions being lumped in.

If the regular conditions come first, like

self.option_loud_drop(14).is_some() && self.option_loud_drop(15).is_some() && let Some(_d) = self.option_loud_drop(18) && let Some(_e) = self.option_loud_drop(17)

we can (and do) wrap them in the same DropTemps, and so they drop in reverse source order.

FTR there is also pretty weird behaviour for vanilla non-let if chains. Drop behaviour is currently like:

if self.option_loud_drop(5).is_some() && self.option_loud_drop(1).is_some() && self.option_loud_drop(2).is_some() && self.option_loud_drop(3).is_some() && self.option_loud_drop(4).is_some() { self.print(6); }

Same goes if you put the expression into a let _= ..., or replace the && with a || (while changing the is_some to is_none so that all partial exprs get evaluated). So second sub-expression is first, then it goes in normal direction, until the end. Then comes the first sub-expression. Non-short-circuiting & and | drop more consistently in inverse order (5,4,3,2,1). I'm not sure how to resolve this, and how to integrate this with let chains. There is the danger of furthering technical debt on one hand, on the other hand there is the danger of adding exceptions.

A bit unrelated: Generally I think that dropping the temporaries of the if let expression after the else block is entered was a mistake. Ideally it should be changed to always pre-drop, like what if is doing. I think let chains give us a good opportunity to switch to the new behaviour, at least for let chains, and I'm very happy that currently this is what this PR seems to be doing: drop all temporaries, from let or from an expression, before the else block is entered. Just as a positive feedback :).

Rollup of 6 pull requests Successful merges: - rust-lang#102773 (Use semaphores for thread parking on Apple platforms) - rust-lang#102884 (resolve: Some cleanup, asserts and tests for lifetime ribs) - rust-lang#102954 (Add missing checks for `doc(cfg_hide(...))`) - rust-lang#102998 (Drop temporaries created in a condition, even if it's a let chain) - rust-lang#103003 (Fix `suggest_floating_point_literal` ICE) - rust-lang#103041 (Update cargo) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup

Stabilize let chains in the 2024 edition # Stabilization report This proposes the stabilization of `let_chains` ([tracking issue], [RFC 2497]) in the [2024 edition] of Rust. [tracking issue]: rust-lang#53667 [RFC 2497]: rust-lang/rfcs#2497 [2024 edition]: https://doc.rust-lang.org/nightly/edition-guide/rust-2024/index.html ## What is being stabilized The ability to `&&`-chain `let` statements inside `if` and `while` is being stabilized, allowing intermixture with boolean expressions. The patterns inside the `let` sub-expressions can be irrefutable or refutable. ```Rust struct FnCall<'a> { fn_name: &'a str, args: Vec<i32>, } fn is_legal_ident(s: &str) -> bool { s.chars() .all(|c| ('a'..='z').contains(&c) || ('A'..='Z').contains(&c)) } impl<'a> FnCall<'a> { fn parse(s: &'a str) -> Option<Self> { if let Some((fn_name, after_name)) = s.split_once("(") && !fn_name.is_empty() && is_legal_ident(fn_name) && let Some((args_str, "")) = after_name.rsplit_once(")") { let args = args_str .split(',') .map(|arg| arg.parse()) .collect::<Result<Vec<_>, _>>(); args.ok().map(|args| FnCall { fn_name, args }) } else { None } } fn exec(&self) -> Option<i32> { let iter = self.args.iter().copied(); match self.fn_name { "sum" => Some(iter.sum()), "max" => iter.max(), "min" => iter.min(), _ => None, } } } fn main() { println!("{:?}", FnCall::parse("sum(1,2,3)").unwrap().exec()); println!("{:?}", FnCall::parse("max(4,5)").unwrap().exec()); } ``` The feature will only be stabilized for the 2024 edition and future editions. Users of past editions will get an error with a hint to update the edition. closes rust-lang#53667 ## Why 2024 edition? Rust generally tries to ship new features to all editions. So even the oldest editions receive the newest features. However, sometimes a feature requires a breaking change so much that offering the feature without the breaking change makes no sense. This occurs rarely, but has happened in the 2018 edition already with `async` and `await` syntax. It required an edition boundary in order for `async`/`await` to become keywords, and the entire feature foots on those keywords. In the instance of let chains, the issue is the drop order of `if let` chains. If we want `if let` chains to be compatible with `if let`, drop order makes it hard for us to [generate correct MIR]. It would be strange to have different behaviour for `if let ... {}` and `if true && let ... {}`. So it's better to [stay consistent with `if let`]. In edition 2024, [drop order changes] have been introduced to make `if let` temporaries be lived more shortly. These changes also affected `if let` chains. These changes make sense even if you don't take the `if let` chains MIR generation problem into account. But if we want to use them as the solution to the MIR generation problem, we need to restrict let chains to edition 2024 and beyond: for let chains, it's not just a change towards more sensible behaviour, but one required for correct function. [generate correct MIR]: rust-lang#104843 [stay consistent with `if let`]: rust-lang#103293 (comment) [drop order changes]: rust-lang#124085 ## Introduction considerations As edition 2024 is very new, this stabilization PR only makes it possible to use let chains on 2024 without that feature gate, it doesn't mark that feature gate as stable/removed. I would propose to continue offering the `let_chains` feature (behind a feature gate) for a limited time (maybe 3 months after stabilization?) on older editions to allow nightly users to adopt edition 2024 at their own pace. After that, the feature gate shall be marked as *stabilized*, not removed, and replaced by an error on editions 2021 and below. ## Implementation history * History from before March 14, 2022 can be found in the [original stabilization PR] that was reverted. * rust-lang#94927 * rust-lang#94951 * rust-lang#94974 * rust-lang#95008 * rust-lang#97295 * rust-lang#98633 * rust-lang#99731 * rust-lang#102394 * rust-lang#100526 * rust-lang#100538 * rust-lang#102998 * rust-lang#103405 * rust-lang#103293 * rust-lang#107251 * rust-lang#110568 * rust-lang#115677 * rust-lang#117743 * rust-lang#117770 * rust-lang#118191 * rust-lang#119554 * rust-lang#129394 * rust-lang#132828 * rust-lang/reference#1179 * rust-lang/reference#1251 * rust-lang/rustfmt#5910 [original stabilization PR]: rust-lang#94927 ## Adoption history ### In the compiler * History before March 14, 2022 can be found in the [original stabilization PR]. * rust-lang#115983 * rust-lang#116549 * rust-lang#116688 ### Outside of the compiler * rust-lang/rust-clippy#11750 * [rspack](https://github.com/web-infra-dev/rspack) * [risingwave](https://github.com/risingwavelabs/risingwave) * [dylint](https://github.com/trailofbits/dylint) * [convex-backend](https://github.com/get-convex/convex-backend) * [tikv](https://github.com/tikv/tikv) * [Daft](https://github.com/Eventual-Inc/Daft) * [greptimedb](https://github.com/GreptimeTeam/greptimedb) ## Tests <details> ### Intentional restrictions [`partially-macro-expanded.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2294-if-let-guard/partially-macro-expanded.rs), [`macro-expanded.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2294-if-let-guard/macro-expanded.rs): it is possible to use macros to expand to both the pattern and the expression inside a let chain, but not to the entire `let pat = expr` operand. [`parens.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2294-if-let-guard/parens.rs): `if (let pat = expr)` is not allowed in chains [`ensure-that-let-else-does-not-interact-with-let-chains.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/ensure-that-let-else-does-not-interact-with-let-chains.rs): `let...else` doesn't support chaining. ### Overlap with match guards [`move-guard-if-let-chain.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2294-if-let-guard/move-guard-if-let-chain.rs): test for the `use moved value` error working well in match guards. could maybe be extended with let chains that have more than one `let` [`shadowing.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2294-if-let-guard/shadowing.rs): shadowing in if let guards works as expected [`ast-validate-guards.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/ast-validate-guards.rs): let chains in match guards require the match guards feature gate ### Simple cases from the early days PR rust-lang#88642 has added some tests with very simple usages of `let else`, mostly as regression tests to early bugs. [`then-else-blocks.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/then-else-blocks.rs) [`ast-lowering-does-not-wrap-let-chains.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/ast-lowering-does-not-wrap-let-chains.rs) [`issue-90722.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/issue-90722.rs) [`issue-92145.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/issue-92145.rs) ### Drop order/MIR scoping tests [`issue-100276.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/drop/issue-100276.rs): let expressions on RHS aren't terminating scopes [`drop_order.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/drop/drop_order.rs): exhaustive temporary drop order test for various Rust constructs, including let chains [`scope.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2294-if-let-guard/scope.rs): match guard scoping test [`drop-scope.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2294-if-let-guard/drop-scope.rs): another match guard scoping test, ensuring that temporaries in if-let guards live for the arm [`drop_order_if_let_rescope.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/drop/drop_order_if_let_rescope.rs): if let rescoping on edition 2024, including chains [`mir_let_chains_drop_order.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/mir/mir_let_chains_drop_order.rs): comprehensive drop order test for let chains, distinguishes editions 2021 and 2024. [`issue-99938.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/issue-99938.rs), [`issue-99852.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/mir/issue-99852.rs) both bad MIR ICEs fixed by rust-lang#102394 ### Linting [`irrefutable-lets.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/irrefutable-lets.rs): trailing and leading irrefutable let patterns get linted for, others don't. The lint is turned off for `else if`. [`issue-121070-let-range.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/lint/issue-121070-let-range.rs): regression test for false positive of the unused parens lint, precedence requires the `()`s here ### Parser: intentional restrictions [`disallowed-positions.rs`](https://github.com/rust-lang/rust/blob/2128d8df0e858edcbe6a0861bac948b88b7fabc3/tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs): `let` in expression context is rejected everywhere except at the top level [`invalid-let-in-a-valid-let-context.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/invalid-let-in-a-valid-let-context.rs): nested `let` is not allowed (let's are no legal expressions just because they are allowed in `if` and `while`). ### Parser: recovery [`issue-103381.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/parser/issues/issue-103381.rs): Graceful recovery of incorrect chaining of `if` and `if let` [`semi-in-let-chain.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/parser/semi-in-let-chain.rs): Ensure that stray `;`s in let chains give nice errors (`if_chain!` users might be accustomed to `;`s) [`deli-ident-issue-1.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/parser/deli-ident-issue-1.rs), [`brace-in-let-chain.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/parser/brace-in-let-chain.rs): Ensure that stray unclosed `{`s in let chains give nice errors and hints ### Misc [`conflicting_bindings.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/pattern/usefulness/conflicting_bindings.rs): the conflicting bindings check also works in let chains. Personally, I'd extend it to chains with multiple let's as well. [`let-chains-attr.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/expr/if/attrs/let-chains-attr.rs): attributes work on let chains ### Tangential tests with `#![feature(let_chains)]` [`if-let.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/coverage/branch/if-let.rs): MC/DC coverage tests for let chains [`logical_or_in_conditional.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/mir-opt/building/logical_or_in_conditional.rs): not really about let chains, more about dropping/scoping behaviour of `||` [`stringify.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/macros/stringify.rs): exhaustive test of the `stringify` macro [`expanded-interpolation.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/unpretty/expanded-interpolation.rs), [`expanded-exhaustive.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/unpretty/expanded-exhaustive.rs): Exhaustive test of `-Zunpretty` [`diverges-not.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-0000-never_patterns/diverges-not.rs): Never type, mostly tangential to let chains </details> ## Possible future work * There is proposals to allow `if let Pat(bindings) = expr {}` to be written as `if expr is Pat(bindings) {}` ([RFC 3573]). `if let` chains are a natural extension of the already existing `if let` syntax, and I'd argue orthogonal towards `is` syntax. * rust-lang/lang-team#297 * One could have similar chaining inside `let ... else` statements. There is no proposed RFC for this however, nor is it implemented on nightly. * Match guards have the `if` keyword as well, but on stable Rust, they don't support `let`. The functionality is available via an unstable feature ([`if_let_guard` tracking issue]). Stabilization of let chains affects this feature in so far as match guards containing let chains now only need the `if_let_guard` feature gate be present instead of also the `let_chains` feature (NOTE: this PR doesn't implement this simplification, it's left for future work). [RFC 3573]: rust-lang/rfcs#3573 [`if_let_guard` tracking issue]: rust-lang#51114 ## Open questions / blockers - [ ] bad recovery if you don't put a `let` (I don't think this is a blocker): [rust-lang#117977](rust-lang#117977) - [x] An instance where a temporary lives shorter than with nested ifs, breaking compilation: [rust-lang#103476](rust-lang#103476). Personally I don't think this is a blocker either, as it's an edge case. Edit: turns out to not reproduce in edition 2025 any more, due to let rescoping. regression test added in rust-lang#133093 - [x] One should probably extend the tests for `move-guard-if-let-chain.rs` and `conflicting_bindings.rs` to have chains with multiple let's: done in 133093 - [x] Parsing rejection tests: addressed by rust-lang#132828 - [x] [Style](https://rust-lang.zulipchat.com/#narrow/channel/346005-t-style/topic/let.20chains.20stabilization.20and.20formatting): rust-lang#139456 - [x] rust-lang#86730 explicitly mentions `let_else`. I think we can live with `let pat = expr` not evaluating as `expr` for macro_rules macros, especially given that `let pat = expr` is not a legal expression anywhere except inside `if` and `while`. - [x] Documentation in the reference: rust-lang/reference#1740 - [x] Add chapter to the Rust 2024 [edition guide]: rust-lang/edition-guide#337 - [x] Resolve open questions on desired drop order. [original reference PR]: rust-lang/reference#1179 [edition guide]: https://github.com/rust-lang/edition-guide

Stabilize let chains in the 2024 edition # Stabilization report This proposes the stabilization of `let_chains` ([tracking issue], [RFC 2497]) in the [2024 edition] of Rust. [tracking issue]: rust-lang/rust#53667 [RFC 2497]: rust-lang/rfcs#2497 [2024 edition]: https://doc.rust-lang.org/nightly/edition-guide/rust-2024/index.html ## What is being stabilized The ability to `&&`-chain `let` statements inside `if` and `while` is being stabilized, allowing intermixture with boolean expressions. The patterns inside the `let` sub-expressions can be irrefutable or refutable. ```Rust struct FnCall<'a> { fn_name: &'a str, args: Vec<i32>, } fn is_legal_ident(s: &str) -> bool { s.chars() .all(|c| ('a'..='z').contains(&c) || ('A'..='Z').contains(&c)) } impl<'a> FnCall<'a> { fn parse(s: &'a str) -> Option<Self> { if let Some((fn_name, after_name)) = s.split_once("(") && !fn_name.is_empty() && is_legal_ident(fn_name) && let Some((args_str, "")) = after_name.rsplit_once(")") { let args = args_str .split(',') .map(|arg| arg.parse()) .collect::<Result<Vec<_>, _>>(); args.ok().map(|args| FnCall { fn_name, args }) } else { None } } fn exec(&self) -> Option<i32> { let iter = self.args.iter().copied(); match self.fn_name { "sum" => Some(iter.sum()), "max" => iter.max(), "min" => iter.min(), _ => None, } } } fn main() { println!("{:?}", FnCall::parse("sum(1,2,3)").unwrap().exec()); println!("{:?}", FnCall::parse("max(4,5)").unwrap().exec()); } ``` The feature will only be stabilized for the 2024 edition and future editions. Users of past editions will get an error with a hint to update the edition. closes #53667 ## Why 2024 edition? Rust generally tries to ship new features to all editions. So even the oldest editions receive the newest features. However, sometimes a feature requires a breaking change so much that offering the feature without the breaking change makes no sense. This occurs rarely, but has happened in the 2018 edition already with `async` and `await` syntax. It required an edition boundary in order for `async`/`await` to become keywords, and the entire feature foots on those keywords. In the instance of let chains, the issue is the drop order of `if let` chains. If we want `if let` chains to be compatible with `if let`, drop order makes it hard for us to [generate correct MIR]. It would be strange to have different behaviour for `if let ... {}` and `if true && let ... {}`. So it's better to [stay consistent with `if let`]. In edition 2024, [drop order changes] have been introduced to make `if let` temporaries be lived more shortly. These changes also affected `if let` chains. These changes make sense even if you don't take the `if let` chains MIR generation problem into account. But if we want to use them as the solution to the MIR generation problem, we need to restrict let chains to edition 2024 and beyond: for let chains, it's not just a change towards more sensible behaviour, but one required for correct function. [generate correct MIR]: rust-lang/rust#104843 [stay consistent with `if let`]: rust-lang/rust#103293 (comment) [drop order changes]: rust-lang/rust#124085 ## Introduction considerations As edition 2024 is very new, this stabilization PR only makes it possible to use let chains on 2024 without that feature gate, it doesn't mark that feature gate as stable/removed. I would propose to continue offering the `let_chains` feature (behind a feature gate) for a limited time (maybe 3 months after stabilization?) on older editions to allow nightly users to adopt edition 2024 at their own pace. After that, the feature gate shall be marked as *stabilized*, not removed, and replaced by an error on editions 2021 and below. ## Implementation history * History from before March 14, 2022 can be found in the [original stabilization PR] that was reverted. * rust-lang/rust#94927 * rust-lang/rust#94951 * rust-lang/rust#94974 * rust-lang/rust#95008 * rust-lang/rust#97295 * rust-lang/rust#98633 * rust-lang/rust#99731 * rust-lang/rust#102394 * rust-lang/rust#100526 * rust-lang/rust#100538 * rust-lang/rust#102998 * rust-lang/rust#103405 * rust-lang/rust#103293 * rust-lang/rust#107251 * rust-lang/rust#110568 * rust-lang/rust#115677 * rust-lang/rust#117743 * rust-lang/rust#117770 * rust-lang/rust#118191 * rust-lang/rust#119554 * rust-lang/rust#129394 * rust-lang/rust#132828 * rust-lang/reference#1179 * rust-lang/reference#1251 * rust-lang/rustfmt#5910 [original stabilization PR]: rust-lang/rust#94927 ## Adoption history ### In the compiler * History before March 14, 2022 can be found in the [original stabilization PR]. * rust-lang/rust#115983 * rust-lang/rust#116549 * rust-lang/rust#116688 ### Outside of the compiler * rust-lang/rust-clippy#11750 * [rspack](https://github.com/web-infra-dev/rspack) * [risingwave](https://github.com/risingwavelabs/risingwave) * [dylint](https://github.com/trailofbits/dylint) * [convex-backend](https://github.com/get-convex/convex-backend) * [tikv](https://github.com/tikv/tikv) * [Daft](https://github.com/Eventual-Inc/Daft) * [greptimedb](https://github.com/GreptimeTeam/greptimedb) ## Tests <details> ### Intentional restrictions [`partially-macro-expanded.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2294-if-let-guard/partially-macro-expanded.rs), [`macro-expanded.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2294-if-let-guard/macro-expanded.rs): it is possible to use macros to expand to both the pattern and the expression inside a let chain, but not to the entire `let pat = expr` operand. [`parens.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2294-if-let-guard/parens.rs): `if (let pat = expr)` is not allowed in chains [`ensure-that-let-else-does-not-interact-with-let-chains.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/ensure-that-let-else-does-not-interact-with-let-chains.rs): `let...else` doesn't support chaining. ### Overlap with match guards [`move-guard-if-let-chain.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2294-if-let-guard/move-guard-if-let-chain.rs): test for the `use moved value` error working well in match guards. could maybe be extended with let chains that have more than one `let` [`shadowing.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2294-if-let-guard/shadowing.rs): shadowing in if let guards works as expected [`ast-validate-guards.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/ast-validate-guards.rs): let chains in match guards require the match guards feature gate ### Simple cases from the early days PR #88642 has added some tests with very simple usages of `let else`, mostly as regression tests to early bugs. [`then-else-blocks.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/then-else-blocks.rs) [`ast-lowering-does-not-wrap-let-chains.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/ast-lowering-does-not-wrap-let-chains.rs) [`issue-90722.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/issue-90722.rs) [`issue-92145.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/issue-92145.rs) ### Drop order/MIR scoping tests [`issue-100276.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/drop/issue-100276.rs): let expressions on RHS aren't terminating scopes [`drop_order.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/drop/drop_order.rs): exhaustive temporary drop order test for various Rust constructs, including let chains [`scope.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2294-if-let-guard/scope.rs): match guard scoping test [`drop-scope.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2294-if-let-guard/drop-scope.rs): another match guard scoping test, ensuring that temporaries in if-let guards live for the arm [`drop_order_if_let_rescope.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/drop/drop_order_if_let_rescope.rs): if let rescoping on edition 2024, including chains [`mir_let_chains_drop_order.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/mir/mir_let_chains_drop_order.rs): comprehensive drop order test for let chains, distinguishes editions 2021 and 2024. [`issue-99938.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/issue-99938.rs), [`issue-99852.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/mir/issue-99852.rs) both bad MIR ICEs fixed by #102394 ### Linting [`irrefutable-lets.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/irrefutable-lets.rs): trailing and leading irrefutable let patterns get linted for, others don't. The lint is turned off for `else if`. [`issue-121070-let-range.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/lint/issue-121070-let-range.rs): regression test for false positive of the unused parens lint, precedence requires the `()`s here ### Parser: intentional restrictions [`disallowed-positions.rs`](https://github.com/rust-lang/rust/blob/2128d8df0e858edcbe6a0861bac948b88b7fabc3/tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs): `let` in expression context is rejected everywhere except at the top level [`invalid-let-in-a-valid-let-context.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/invalid-let-in-a-valid-let-context.rs): nested `let` is not allowed (let's are no legal expressions just because they are allowed in `if` and `while`). ### Parser: recovery [`issue-103381.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/parser/issues/issue-103381.rs): Graceful recovery of incorrect chaining of `if` and `if let` [`semi-in-let-chain.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/parser/semi-in-let-chain.rs): Ensure that stray `;`s in let chains give nice errors (`if_chain!` users might be accustomed to `;`s) [`deli-ident-issue-1.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/parser/deli-ident-issue-1.rs), [`brace-in-let-chain.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/parser/brace-in-let-chain.rs): Ensure that stray unclosed `{`s in let chains give nice errors and hints ### Misc [`conflicting_bindings.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/pattern/usefulness/conflicting_bindings.rs): the conflicting bindings check also works in let chains. Personally, I'd extend it to chains with multiple let's as well. [`let-chains-attr.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/expr/if/attrs/let-chains-attr.rs): attributes work on let chains ### Tangential tests with `#![feature(let_chains)]` [`if-let.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/coverage/branch/if-let.rs): MC/DC coverage tests for let chains [`logical_or_in_conditional.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/mir-opt/building/logical_or_in_conditional.rs): not really about let chains, more about dropping/scoping behaviour of `||` [`stringify.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/macros/stringify.rs): exhaustive test of the `stringify` macro [`expanded-interpolation.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/unpretty/expanded-interpolation.rs), [`expanded-exhaustive.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/unpretty/expanded-exhaustive.rs): Exhaustive test of `-Zunpretty` [`diverges-not.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-0000-never_patterns/diverges-not.rs): Never type, mostly tangential to let chains </details> ## Possible future work * There is proposals to allow `if let Pat(bindings) = expr {}` to be written as `if expr is Pat(bindings) {}` ([RFC 3573]). `if let` chains are a natural extension of the already existing `if let` syntax, and I'd argue orthogonal towards `is` syntax. * rust-lang/lang-team#297 * One could have similar chaining inside `let ... else` statements. There is no proposed RFC for this however, nor is it implemented on nightly. * Match guards have the `if` keyword as well, but on stable Rust, they don't support `let`. The functionality is available via an unstable feature ([`if_let_guard` tracking issue]). Stabilization of let chains affects this feature in so far as match guards containing let chains now only need the `if_let_guard` feature gate be present instead of also the `let_chains` feature (NOTE: this PR doesn't implement this simplification, it's left for future work). [RFC 3573]: rust-lang/rfcs#3573 [`if_let_guard` tracking issue]: rust-lang/rust#51114 ## Open questions / blockers - [ ] bad recovery if you don't put a `let` (I don't think this is a blocker): [#117977](rust-lang/rust#117977) - [x] An instance where a temporary lives shorter than with nested ifs, breaking compilation: [#103476](rust-lang/rust#103476). Personally I don't think this is a blocker either, as it's an edge case. Edit: turns out to not reproduce in edition 2025 any more, due to let rescoping. regression test added in #133093 - [x] One should probably extend the tests for `move-guard-if-let-chain.rs` and `conflicting_bindings.rs` to have chains with multiple let's: done in 133093 - [x] Parsing rejection tests: addressed by rust-lang/rust#132828 - [x] [Style](https://rust-lang.zulipchat.com/#narrow/channel/346005-t-style/topic/let.20chains.20stabilization.20and.20formatting): rust-lang/rust#139456 - [x] rust-lang/rust#86730 explicitly mentions `let_else`. I think we can live with `let pat = expr` not evaluating as `expr` for macro_rules macros, especially given that `let pat = expr` is not a legal expression anywhere except inside `if` and `while`. - [x] Documentation in the reference: rust-lang/reference#1740 - [x] Add chapter to the Rust 2024 [edition guide]: rust-lang/edition-guide#337 - [x] Resolve open questions on desired drop order. [original reference PR]: rust-lang/reference#1179 [edition guide]: https://github.com/rust-lang/edition-guide

Let chains should still drop temporaries

ad8b242

by the end of the condition's execution

rust-highfive assigned davidtwco Oct 13, 2022

rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Oct 13, 2022

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 13, 2022

est31 reviewed Oct 13, 2022

View reviewed changes

src/test/ui/drop/drop_order.rs Show resolved Hide resolved

This comment has been minimized.

Sign in to view

compiler-errors reviewed Oct 13, 2022

View reviewed changes

compiler/rustc_ast_lowering/src/expr.rs Outdated Show resolved Hide resolved

compiler-errors reviewed Oct 13, 2022

View reviewed changes

compiler/rustc_ast_lowering/src/expr.rs Show resolved Hide resolved

rust-highfive assigned compiler-errors and unassigned davidtwco Oct 13, 2022

rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 13, 2022

rust-highfive assigned eholk Oct 13, 2022

rustbot added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Oct 13, 2022

rust-highfive unassigned compiler-errors Oct 13, 2022

nathanwhit added 2 commits October 13, 2022 18:20

Lower condition directly from AST to HIR

709a08a

Validate MIR in the drop_order test

4e1c09d

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Oct 14, 2022

bors removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 14, 2022

bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Oct 14, 2022

cjgillot reviewed Oct 14, 2022

View reviewed changes

Dylan-DPC mentioned this pull request Oct 15, 2022

Rollup of 6 pull requests #103083

Merged

bors merged commit b79ad57 into rust-lang:master Oct 15, 2022

rustbot added this to the 1.66.0 milestone Oct 15, 2022

This was referenced Oct 16, 2022

let_chains desugaring is wrong #100513

Closed

Drop order twist of && and || chains #103107

Closed

est31 mentioned this pull request Nov 1, 2022

Tracking issue for eRFC 2497, "if- and while-let-chains, take 2" #53667

Closed

15 tasks

est31 mentioned this pull request Nov 10, 2024

Stabilize let chains in the 2024 edition #132833

Merged

9 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Drop temporaries created in a condition, even if it's a let chain #102998

Drop temporaries created in a condition, even if it's a let chain #102998

nathanwhit commented Oct 13, 2022

rust-highfive commented Oct 13, 2022

nathanwhit commented Oct 13, 2022

This comment has been minimized.

Noratrieb commented Oct 13, 2022

davidtwco commented Oct 13, 2022

compiler-errors commented Oct 13, 2022

eholk commented Oct 13, 2022

nathanwhit commented Oct 14, 2022

nathanwhit commented Oct 14, 2022 •

edited

Loading

joshtriplett commented Oct 14, 2022

eholk commented Oct 14, 2022

bors commented Oct 14, 2022

cjgillot Oct 14, 2022

nathanwhit Oct 14, 2022 •

edited

Loading

est31 Oct 14, 2022

Drop temporaries created in a condition, even if it's a let chain #102998

Drop temporaries created in a condition, even if it's a let chain #102998

Conversation

nathanwhit commented Oct 13, 2022

rust-highfive commented Oct 13, 2022

nathanwhit commented Oct 13, 2022

This comment has been minimized.

Noratrieb commented Oct 13, 2022

davidtwco commented Oct 13, 2022

compiler-errors commented Oct 13, 2022

eholk commented Oct 13, 2022

nathanwhit commented Oct 14, 2022

nathanwhit commented Oct 14, 2022 • edited Loading

joshtriplett commented Oct 14, 2022

eholk commented Oct 14, 2022

bors commented Oct 14, 2022

cjgillot Oct 14, 2022

Choose a reason for hiding this comment

nathanwhit Oct 14, 2022 • edited Loading

Choose a reason for hiding this comment

est31 Oct 14, 2022

Choose a reason for hiding this comment

nathanwhit commented Oct 14, 2022 •

edited

Loading

nathanwhit Oct 14, 2022 •

edited

Loading